TSN (Time-Sensitive Networking) extends the functionality of Ethernet networks to support a deterministic and high-availability communication on Layer 2 of the seven layer Open Systems Interconnect (OSI) model. TSN is typically used to support applications for industrial automation and control applications. For example, these applications may support a manufacturing assembly line, audio/video streaming, autonomous driving, electrical control systems, chemical control systems, and other applications where precise real-time coordinated control of multiple devices may be required. In a typical TSN, time may originate and be communicated using a variety of known protocols and communication technologies including but not limited to, Global Positioning Satellite (GPS), Industrial Ethernet, Peripheral Component Interconnect Express (PCIe), Precision Time Means (PTM), Industrial Communications Subsystem (ICSS), and Common Platform Time Sync (CPTS). TSN is a set of standards under development by the Time-Sensitive Networking task group of the IEEE 802.1 working group. Time in a TSN network is usually distributed from one central time source directly through the network itself using the IEEE 1588 Precision Time Protocol, which utilizes Ethernet frames to distribute time synchronization information (e.g., time sync info). In addition to the IEEE 1588 specification there is a subset of overall options available for TSN implementations that is referred to as IEEE 802.1AS. The subset narrows the complete list of IEEE 1588 options down to a manageable few critical options that are applicable to Home networks or networks in automotive car or industrial automation environments. Each of these specifications is available from the IEEE and incorporated herein by reference in their entirety. For conciseness, the details of time transmission within actual Ethernet frames (i.e., the structure of the packets) will not be repeated directly in this disclosure but may be found in the above mentioned specifications.
In addition to controlling devices, TSN applications may be used to perform mission critical monitoring of sensors to coordinate and correlate readings taken at different points (e.g., different locations or different phases) of an overall system. In order to achieve appropriate real-time scheduling, all the components in the TSN that must function in a coordinated manner with high precision timing information must receive that timing information consistently with each other. Actual real-world clock time is not necessarily as important as a time domain that explains to other portions of the overall system how to work relative to each other. In such a system, it is normal to have multiple time domains for multiple sets of different functions. Each set of highly related functions may be assigned to a single domain for either communication, application, or both. Other sets of highly integrated functions may be in a second domain. There may also be a relation maintained to understand time differences across the different domains and types of domains (both communication and application). For example, normally individual processors in the system may have a separate application time domain from a communication time domain for that processor. In addition, each type time domain may also have multiple time masters to drive synchronization and for redundancy purpose (e.g., system failure of device or communication interruption).
In current systems utilizing TSN information and coordinating across different domains, a software approach is utilized. In a software solution, the accuracy of time coordination and deviation thereof may be on the order of milliseconds (ms) or worse. In contrast, the hardware mechanism described in this disclosure may achieve nanosecond (ns) accuracy. As will be recognized, accuracy of the timing synchronization may be directly translated to a more deterministic network and, in turn, provide better support for real-time applications used in industrial automation and industrial control.
The examples of this disclosure may also provide a hardware mechanism to allow each peripheral to choose its master clock domain source independently. This increased flexibility and functionality may further provide a graceful way for any specific peripheral (e.g., processor, device, time consumer) to change its time domain master, and possibly that peripheral's input time source (e.g., GPS, industrial Ethernet, PCIe, etc.) during run time. Changing a time domain master may be required for many different reasons including redundancy and fail-over capabilities.